Method for generating customer secure card numbers

ABSTRACT

A method for providing secure transactions generates a Secure Card Number (“SCN”) for a first entity that is transferred with a first entity identifier to a second entity and then to a money source that verifies that the transaction is valid by use of the first entity identifier and the SCN. The SCN includes a Transaction Information Block (“TIB”), a Counter Block, and an encrypted Personal Identification Number (“PIN”) Block. The SCN is transferred to the money source in an account number or a non-account data field. The money source can use the TIB to determine whether the SCN should be used once or multiple times or to identify one of several physical devices, all of which are issued to the first entity, used to generate the SCN. The money source validates the SCN by duplicating the encryption process used to create an encrypted PIN Block and comparing the result to the encrypted PIN Block received with the transaction. A Triple Data Encryption Standard algorithm encrypts a PIN Block generated from a PIN, a Sequence Insertion Number (“SIN”) and a known starting value. The SIN can be a combination of three seed values and a random value generated by a Pseudo Random Number Generator (“PRNG”) initialized with the seed values. A Counter value is associated with the Counter Block and the seed values.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. application Ser. No.09/960,715, filed Sep. 21, 2001, incorporated herein by reference, andis related to U.S. application Ser. Nos. 09/667,081 and 09/667,089 filedSep. 21, 2000, both of which are now abandoned, which arecontinuation-in-part applications of U.S. Ser. No. 09/659,434, filedSep. 8, 2000, now abandoned, which is a continuation-in-part of U.S.Ser. No. 09/640,044, filed Aug. 15, 2000, now abandoned, which is acontinuation-in-part of U.S. Ser. No. 09/619,859, filed Jul. 20, 2000,now abandoned, which is a continuation-in-part of U.S. Ser. No.09/571,707, now U.S. Pat. No. 6,592,044, all of which are incorporatedherein by reference. This application is also related to U.S.application Ser. No. 09/960,714 filed Sep. 21, 2001, now U.S. Pat. No.6,805,288, incorporated herein by reference.

FIELD OF THE INVENTION

The present invention is in the field of payment systems.

BACKGROUND OF THE INVENTION

Three forms of money in widespread use today throughout the world arecash, checks and payment cards (debit or credit). Each has distinctadvantages, and distinct disadvantages. Cash is readily accepted, easyto use and anonymous, but it does not earn interest, it can be lost orstolen, and it is not always readily accessible. Checks are not alwaysaccepted, but they offer many advantages, since they do not have to bewritten until the time of payment. However, they must be physicallypresented and they are not anonymous. Payment cards are readily, but notalways, accepted, and they offer many advantages over checks. If thecard is a credit card, payment can be deferred, but the transaction isnot anonymous. If the card is a debit card, payment has usually beenmade prior to its use, but it is anonymous. Accordingly, it is apparentthat different types of money have different advantages to differentpersons in different situations. This may be one reason why all theseforms of money are still in widespread use, and are even used by thesame persons at different times.

As society and international commerce have become more dependent uponelectronic transactions, money has also become more electronic. Manyattempts have been made to come up with suitable forms of electronicmoney that mimic the physical world, or even create new forms ofelectronic money. However, despite the enormous need for such money, andefforts by some of the best minds and most successful companies in theworld, electronic money has suffered many setbacks and been far slowerto materialize than many had hoped or predicted. The reasons are manyand varied, but some of the obvious reasons are security, ease ofuse/operation, and unwillingness of the public and/or commerce to makeradical changes or embrace new technology and/or procedures. As aresult, many efforts, including several potentially promising efforts,have met with failure.

Even though new forms of electronic money have been slow to develop orgain widespread acceptance, electronic payments have still movedforward. Many banks now offer some form of electronic checking. Andpayment cards have been used for electronic transactions in e-commerceand m-commerce (mobile commerce). Still, there is widespread concernabout the safety of such transactions, and recent news stories haveuncovered widespread fraudulent activity associated with use oftraditional credit card numbers in e-commerce over the Internet. Inaddition, there is growing concern about consumer privacy, or lackthereof, due to widespread electronic profiling of consumers who makeelectronic payments.

Although the media has been quick to cover fraud associated with use ofcredit cards over the Internet, it is often overlooked, at least by thepublic and the media (but not the credit card companies), that themajority of fraudulent activity concerning credit cards is notassociated with e-commerce activity. Most fraud occurs in the “brick andmortar” world, and the numbers are daunting. Despite many attempts tocombat unauthorized or fraudulent use of credit cards, it is estimatedthat credit card fraud now exceeds hundreds of millions, if not severalbillion, dollars per year. And this does not even count the cost ofinconvenience to consumers, merchants and credit card issuer/providers,or the emotional distress caused to victims of such fraud, or the costto society in terms of law enforcement and preventative activities.

Accordingly, there is a very real, long-felt need to reduce the amountof fraudulent activity that is associated with credit cards, and thisneed has only grown more acute as consumers and commerce search forbetter ways to purchase and sell goods and services via e-commerce andm-commerce. However, any solution needs to be something that isacceptable to the public at large. It should be easy to use. It shouldnot be complicated or expensive to implement. Preferably, it should fitwithin the existing infrastructure, and not be something that requires agreat deal of educational effort, or a radical change in behavior orhabits of consumers. In other words, it should be user friendly, readilyunderstandable and something that does not require a completely newinfrastructure, which is a reason suggested by some as to why smartcards have not been widely accepted in the United States.

In addition, it is highly desirable that any solution to such problemsbe capable of widespread use, in many different platforms, for manydifferent applications.

In U.S. Pat. No. 5,956,699 issued in September of 1999, Wong andAnderson were the first to introduce the methodology of a system forsecure and anonymous credit card transactions on the Internet. Thispatent introduced a system which used an algorithm to use one's ownselected Personal Identification Number (PIN) as one's own de factodigital signature. The algorithm instructs the cardholder how to insertone's PIN into one's valid credit card number before using it for anytransactions on the Internet. The resultant scrambled up credit cardnumber, which is tailored by the algorithm to having the same number ofdigits as before, is rendered useless on the Internet because the PINinsertion algorithm is changed automatically after every transaction.This methodology is not only capable of drastically reducing credit cardfraud on the Internet, it is also capable of safeguarding one'sanonymity, and thus privacy, in credit card purchases on the Internet.

After the issuance of U.S. Pat. No. 5,956,699, Wong et al. also inventedan anonymous electronic card for generating personal coupons useful incommercial and security transactions, a method for implementinganonymous credit card transactions using a fictitious account name, aswell as methods for generating one-time unique numbers that can be usedin credit card transactions in the brick and mortar world, e-commerce,m-commerce and in many other applications.

The present invention seeks to provide new methods for generating andprocessing Secure Card Numbers (SCN) that can be used in all types oftransactions in which a conventional credit card account number isaccepted. In addition, the present invention conforms to the existingstandards for PIN encryption as promulgated by the American BankersAssociation (ABA), the American National Standards Institute (ANSI), theInternational Standards Organization (ISO), and the Federal InformationProcessing Standards (FIPS) Publications of the National Institute ofStandards and Technology (NIST). Because the methodology is well suitedfor use in hardware and software applications, it has widespreadapplicability to many different types of transactions.

The present invention is related to the concept of customer one-timeunique purchase order numbers (“Coupons”) as described in U.S. Ser. No.09/640,044. An algorithm is executed that uses a user account number, acustomer sequence number, a customer permutated user key, and aTransaction Information Block (TIB) as input variables to form an SCNthat is correlated with a sequence number. Combining a user key with auser account number, a user insertion key correlated with the customersequence number, and then encrypting the result using the Triple DataEncryption Standards (TDES), forms the customer permutated user key. Arandom number generator generates the user insertion key that iscorrelated with the sequence number. The TIB may provide several piecesof information, including the conditions under which the SCN will bevalid (i.e., the SCN type), additional account identificationinformation, and the status of the device used for SCN generation. Thesequence number can be changed after each SCN is generated and a new SCNcan then be generated using a new user insertion variable correlated tothe changed sequence number.

After an SCN is generated, it is transferred with a first entityidentifier to a second entity (which can actually be several entities),which then transfers the information to a money source. An individualSCN is verified as being valid by the money source by duplicating thegeneration of the customer permutated user key for the specified firstentity and the specified sequence number, and then comparing it to thecustomer permutated user key which is embedded in the provided SCN.Additionally, the money source verifies that the specified SCN type isvalid given the specific conditions of the transaction. Once verified asvalid, each SCN passes through a life cycle in accordance withconventional credit card processing practices and with its SCN type, inwhich it may be used for various types of transactions before beingretired. If a preselected number of SCNs are received by the moneysource and determined to be invalid (either consecutively or within apredetermined timeframe), then an invalid user account number conditionis set to prevent further attempts to verify SCNs for that first entity.

A user key can be entered into an input device, and validates the userkey by comparing it to a stored user key. If the entered user key isvalid, the user can generate an SCN. The sequence number changes eachtime a user key is entered into the input device.

SUMMARY OF THE INVENTION

The present invention is generally directed to a method for providingone or more secure transactions between a first entity and at least oneadditional entity in which a Secure Card Number (“SCN”) is generated forthe first entity, then transferred with a first entity identifier to asecond entity and then transferred to a money source that verifies thatthe transaction is valid by use of the first entity identifier and theSCN. The SCN includes a Transaction Information Block (“TIB”), a CounterBlock, and an encrypted Personal Identification Number (“PIN”) Block.The SCN can be transferred to the money source in an account numberwhile the first entity identifier is transferred to the money source ina non-account data field or the first entity identifier can betransferred to the money source as an account number while the SCN istransferred to the money source in a non-account data field.

In a first, separate aspect of the present invention, the TIB can beused for invoking one or more restrictions on use of the SCN. The moneysource can use the TIB to determine whether the SCN should be asingle-use SCN (i.e., can only be used for a single transaction by thefirst entity) or a multiple-use SCN (i.e., can be used for multipletransactions between the first entity and a single merchant). The TIBcan also be used by the money source to identify the physical deviceused to generate the SCN.

In another, separate aspect of the present invention, the money sourcevalidates the SCN by duplicating a PIN Block encryption process used tocreate the encrypted PIN and by then comparing the result to theencrypted PIN Block received with the transaction.

In still another, separate aspect of the present invention, theencrypted PIN Block is formed by using a Triple Data Encryption Standardalgorithm (“TDES”) to encrypt a PIN Block. The PIN Block can begenerated from a PIN associated with the first entity, a SequenceInsertion Number (“SIN”) and a starting value known to both the firstentity and to the money source. The SIN can be a combination of a firstset of seed values and a random value generated by a Pseudo RandomNumber Generator (“PRNG”) that was initialized with the first set ofseed values. The first set of seed values is associated with a Countervalue that is associated with Counter Block.

In yet another, separate aspect of the present invention, when the SCNis a nine digit number, the TIB is a one digit number, the Counter Blockis a four digit number, and the encrypted PIN Block is a four digitnumber. The encrypted PIN Block can be created by dividing an 8-byteSequence Insertion Number (“SIN”) into four 2-byte integers (three seedvalues and the random number), adding the PIN and a pre-assignedconstant 4-digit value to each of the four 2-byte integers,concatenating the results to form an 8-byte input block which the TDESencrypts into an 8-byte output block, dividing the 8-byte output blockinto four 2-byte integers x1, x2, x3 and x4 and then using integersx1-x4 to produce the 4-digit encrypted PIN Block with a value P, whereinP=(Ax1+Bx2+Cx3+Dx4) mod 10000, each of the values A, B, C and D beingpre-assigned odd integers.

Accordingly, it is a primary object of the present invention to providea method for generating and processing customer Secure Card Numbers foruse in transactions where conventional credit card numbers are accepted.

This and further objects and advantages will be apparent to thoseskilled in the art in connection with the detailed description of thepreferred embodiment set forth below.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 illustrates an exemplary embodiment.

FIG. 1A illustrates another embodiment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is related to U.S. Pat. Nos. 5,913,203, 5,937,394and 5,956,699, the disclosures of which are all specificallyincorporated herein by reference.

The preferred embodiment of the present invention is adapted for use incredit card transactions, and as such can be used in connection with awide variety of instruments that can be used in connection with suchfinancial transactions: electronic cards, software programs used innetwork applications, telephones (especially telephones used in what isnow being referred to as m-commerce, or mobile commerce), or evenphysical imprint transactions. Moreover, it can be used whether suchtransactions are conducted in person, face-to-face, or whether suchtransactions are conducted by an indirect medium, such as a mail ordertransaction, a transaction conducted over a computer network (forexample, the Internet), or a telephone transaction.

As is the case in most financial transactions, three parties aretypically involved in completed credit card transactions according tothe present invention. A party presents a credit card account numberwith the intent to initiate a monetary payment (or credit/return). Inthe context of the following description, this is the first entity orcustomer. Another party receives the credit card account number with theintent to receive a monetary payment (or credit I return), and thisparty can be a single party or two or more parties. In the context ofthe following description, the party or parties that are receiving thecredit card account number are referred to as the second entity ormerchant. Finally, there is at least one party, and usually multipleparties, that serve as intermediaries to the monetary payment (orcredit/return). The second entity provides the credit card accountnumber to this party over several transactions to effect the monetarypayment (or credit/return): authorization, incremental authorization,authorization reversal, settlement, and credit/return. The intermediarygroup of one or more parties will be referred to in the context of thefollowing description as a money source. Thus, the money source may beone or more banks, a credit card company or any other institutioninvolved with issuance of credit cards or bank debit cards, such as acredit union or other institution, or a money source as described inU.S. Pat. No. 5,913,203.

In connection with the preferred embodiment, it is not necessary thatthe first entity use a real identity, although such an option is alsoacceptable. Instead, a pseudonym, such as a screen name or an alias,could be used to protect the first entity's privacy and provideadditional security.

Although the first entity need not use a real identity, the first entitymust establish an account with a money source. When the account isestablished, the first entity and the money source must agree upon apayment mechanism or protocol. In the case of a credit card or a bankcard, this could be done in the same fashion as exists today, and thefirst entity could select a fictitious account name as is explained ingreater detail in co-pending U.S. patent application Ser. No.09/619,859. It is especially preferred that two different users not beallowed to select the same fictitious account name so that a fictitiousaccount name also represents a unique identifier. However, the preferredembodiment could also be used in connection with a prepaid account. Insuch a scenario, the first entity could simply purchase a prepaid cardand no real identity would ever be required.

When the first entity establishes an account with the money source, auser key must be selected. The user key can be a PIN, similar to thatwhich is currently in widespread use in the United States in connectionwith automated teller machines. Both the first entity and the moneysource must have access to the user key, which can be selected by eitherentity. In order to be able to retrieve this user key, the money sourcemust create a record associated with the first entity that includes theuser key and a first entity identifier (whether this be the real name ofthe first entity or a fictitious account name).

Once the first entity has established an account with the money sourceand a user key has been selected, the first entity must be supplied withthe means to generate a customer SCN. As already described, this couldbe hardware or software, but in either case it will include a useraccount number, a customer random number generator that will be used togenerate user insertion keys that are correlated with a customersequence number, and TDES encryption keys.

The TDES encryption standard is the accepted standard for protecting aPIN during data transmission of financial transactions, as described byISO 9564-1-1991 (Banking—Personal Identification Number Management andSecurity—PIN Protection Principles and Techniques, Section 6.2), ISO9564-2-1991 (Banking—Personal Identification Number Management andSecurity—Approved Algorithms for PIN Encipherment), ANSI X9.52-1998(Triple Data Encryption Algorithm—Modes of Operation), and FIPS PUB 46-3(Data Encryption Standard (DES), dated 1999), the disclosures of whichare specifically incorporated herein by reference.

In order to effectively use TDES for PIN encryption, the PIN must becombined with a new set of randomly generated data for each transaction.Otherwise, the encrypted PIN would always be the same value. A customerrandom number generator, such as the one that is described in U.S.patent application Ser. No. 09/640,044, filed Aug. 15, 2000 and which isgenerally known as a Linear Congruential Generator (LCG), is used forthis purpose. This random number generator is algorithmic (i.e.,pseudo-random)—when starting with the same set of seeds, it alwaysproduces the same sequence of numbers. It can therefore be reproduced bythe money source in order to validate a given SCN. Furthermore, sincethis pseudo random number generator generates its values in areproducible sequence, each of the values in the sequence can beidentified by a Counter value that indicates that number's location inthe sequence. The set of random numbers generated and combined with thePIN are collectively referred to as the Sequence Insertion Number (SIN).

In the real world of credit card transactions, it is not possible toassume that transactions conducted by the first entity in a given orderwill always be received by the money source in that same order.Therefore, the money source method of SCN validation must be based on anembedded sequence value. The Counter value is used for this purpose inthe preferred embodiment.

In general, this method can be used to generate SCNs of many differentlengths. In the conventional credit card processing infrastructure, acredit card number is typically 16 digits in length. Such a numbercomprises three sub-numbers: a 6 digit Bank Identification Number (BIN),a 9-digit account number, and a 1-digit checksum number. For the purposeof being compatible with the existing credit card processinginfrastructure, the SCN could be 9 digits in length, and could take theplace of the account number in the conventional 16-digit credit cardnumber.

In the preferred embodiment, the 9-digit SCN itself comprises threesub-numbers: a 1 digit TIB, a 4 digit Counter Block (which identifiesthe random number being used for encryption), and a 4 digit encryptedPIN Block.

The 1 digit TIB may take on up to 10 different values, each of which mayindicate multiple pieces of information. The TIB can be used todetermine which of a plurality of account numbers associated with thefirst entity should be used for the first transaction. The accountnumbers can represent, for example, different credit card accounts ordifferent payment or credit cards. A first account number might beassociated with the TIB value of 0, a second account number might beassociated with the values of 1 and 2, a third account number might beassociated with values of 3 and 4, and so forth, wherein any odd valuemay be restricted to a one transaction limitation while any even valuemay be used to invoke permission for multiple transactions at a singlemerchant. In the preferred embodiment, a TIB value of 0 indicates thatthe SCN may only be used for one transaction; any attempts to use it forsubsequent transactions will result in a transaction denial from themoney source. A value of 1 indicates the same transaction restrictionsas 0, but also indicates that the device generating the SCN has a lowbattery power condition. A value of 2 indicates that the SCN may be usedfor multiple transactions, but only at a single merchant; any attemptsto use it for subsequent transactions at a different merchant willresult in a transaction denial from the money source. A value of 3indicates the same transaction restrictions as 1, but also indicatesthat the device generating the SCN has a low battery power condition.Furthermore, a set of TIB values (4, 5, 6, 7) might represent the samerestriction and status information as (0, 1, 2, 3), respectively, butfurther indicate that the transaction is associated with a differentsubentity (e.g., the first entity identifier identifies a marriedcouple, and the TIB identifies each individual spouse.) Other valuesmight also be used to enforce additional transaction restrictions inways readily apparent to those skilled in the art.

The TIB can also be used by the money source to uniquely identify aphysical device (such as an electronic card) used to generate the SCN.This aspect of the TIB is especially useful when the money source issuesmore than one card to a first entity. Multiple cards might be issued tothe same person (i.e., the first entity) for different uses, or multiplecards might be issued to the same person for use by differentindividuals (such as family members). In such instances, the TIB canidentify which physical card, issued to the first entity, is used for agiven transaction. When the TIB is used in this way, the TIB can be usedas a customization variable to recognize multiple cards otherwise issuedto a single first entity (which might also be a legal entity, such as acorporation).

The 4-digit Counter Block is unencrypted information provided so thatthe money source may decrypt and validate the SCN. It may be simply theactual Counter value (incremented after each use), but in the preferredembodiment, it is created by adding the Counter value to a startingvalue known to both the first entity and to the money source.

The 4-digit PIN Block is the encrypted information that is used tovalidate the fact that the SCN originated from the first entity. The PINBlock is formed using the PIN, the SIN, and a starting value known toboth the first entity and to the money source. It is encrypted usingTDES, which requires use of three 64-bit keys known to both the firstentity and to the money source. In order to encrypt such a small number(16 bits) with such a high level of encryption (158 bits), the PIN mustfirst be expanded to a 64 bit number, then encrypted, and finallyreduced back to a 16 bit number—and in such a way that it is guaranteedto be different for each transaction.

The SIN is the product of an LCG random number generator that isinitialized with three 2-byte integer seeds—the result of operating theLCG on these seeds is a 2-byte random value. The 8-byte SIN consists ofthe three seeds plus the random value. As a by-product of its operation,the LCG also produces three new seeds, which will be used for the nextiteration of the LCG algorithm. The SIN may therefore be associated witha Counter value that indicates a unique location in the sequence ofseeds and value generated by the LCG. This SIN is used as the randombasis for each successively TDES-encrypted PIN Block, and guarantees aproperly encrypted PIN Block for each transaction. To allow propervalidation of the SCN, the Counter value stored in the Counter block isthe one associated with the SIN used as the random basis for the PINBlock.

The creation of the PIN Block starts by dividing the 8-byte SIN intofour 2-byte integers. The PIN and a predefined constant value are bothadded to each individual 2-byte integer. The results are thenconcatenated back again to form an 8-byte input block to the TDESalgorithm, which encrypts them into an 8-byte output block. The outputblock is then divided back into four 2-byte integers (x1, x2, x3, x4).These four values are then used in the following formula to produce the4-digit PIN Block value P: $\begin{matrix}{{{Formula}\quad 1\text{:}}\quad{{PRNG}\quad{Value}\quad{Calculation}}\quad{P = {\left( {{Ax}_{1}^{+}{Bx}_{2}^{+}{Cx}_{3}^{+}{Dx}_{4}} \right)\quad{mod}\quad 10000}}} & \quad\end{matrix}$

In this formula, the four values (A, B, C, D) are each odd integers. The“mod” calculation is a standard modulo arithmetic operation, and worksas follows: if the resulting number is greater than 10,000 (or 20,000 or30,000, etc.), then the value of 10,000 (or 20,000 or 30,000, etc.) issubtracted from it, leaving a positive four digit value.

Once created, the SCN is transmitted along with the first entityidentifier from the first entity to the second entity and, subsequently,to the money source. In one embodiment, the SCN is used in an accountnumber that replaces the conventional credit card number, and the firstentity identifier is a static 9 digit number pre-assigned to the firstentity that is transferred to the money source in a non-account datafield. In the case of an electronic swipe credit card transaction, thefirst entity identifier is dynamically encoded onto Track 1 and/or Track2 of the magnetic stripe in the area known as the Discretionary DataField, which comprises up to 13 digits of information. In the case of atransaction where the first entity is not present, such as a mail order,telephone order, or Internet order, the first entity identifier istransmitted as part of the Billing Address field in one of may possibleforms. For example, it may be entered as “P.O.Box<first-entity-identifier”.

In an especially preferred embodiment, the SCN is not used in an accountnumber to replace the conventional credit card number, but is insteadused in conjunction with it—the conventional credit card number itselffunctions as the first entity identifier, and the SCN is used as adynamic digital signature to positively identify the first entity and istransferred to the money source in a non-account field of data. In thiscase, the SCN is transmitted either in the Discretionary Data Field ofTrack 1 and/or Track 2 or via the Billing Address in a card-not-presenttransaction.

The Money Source validates the SCN by using the first entity identifierto lookup the information necessary to reproduce the PIN Blockencryption for the first entity: the TDES keys, the LCG Seeds, and thePIN. The Money source determines the Counter value by examining theCounter Block, reproduces the calculation of the PIN Block, and thencompares the results to the received PIN Block to perform the actualvalidation.

The Money Source also validates the usage of the SCN based on theembedded TIB. It therefore enforces the various policies based on thefirst entity's previous transaction history: single-use, multiple-usefor single merchant, card-present only.

In the embodiment when the SCN is used in an account number in place ofthe conventional credit card number, it passes through the standardcredit card transaction life-cycle: initial authorization, potentialincremental authorization, potential authorization reversal, settlement,and potential credit/return. However, in an especially preferredembodiment, the SCN is only used for initial authorization—beyond that,the Money Source performs its standard transaction processing.

The Money Source may detect fraudulent transaction attempts in variousways. In both the embodiment where the SCN replaces the conventionalcredit card number, the Money Source may check for re-use of single-useSCNs, use of SCNs without first entity identifiers when the card is notpresent, re-use of multiple-use/single-merchant SCNs at a differentmerchant, or SCNs with invalid PIN Blocks. Each of these casesrepresents a different type of fraud. The Money Source may take variousactions in response to each of these types of attacks, such as disablingthe account after an excessive number of fraudulent transactionattempts, or returning the code indicating that the merchant shouldretain the credit card being used for the transaction.

In the preferred embodiment, the Money Source detects fraudulentauthorization attempts such as re-use of single-use SCNs, re-use ofmultiple-use/single-merchant SCNs at a different merchant, SCNs withinvalid PIN Blocks, or use of the conventional credit card number on anSCN-enabled account without inclusion of an SCN when the card isnot-present. This last case covers simple Internet fraud attempts, butallows, for example, a manual-entry transaction at a POS machine or animprint transaction. After detecting fraud attempts, the Money Sourcemay take the same types of actions as described above.

It should be noted that the preferred embodiment allows the SCN, whenpaired with a conventional credit card number, to be validated byback-end software that is integrated with the issuing money source'sauthorization and settlement processing. An issuing money source canidentify an SCN-enabled credit card account in an issuer-determinedfashion (e.g., a unique Bank Identification Number). It then forwardsselect transaction information to the SCN-enabling software, which isinstalled behind the issuing money source's firewall, which validatesthe SCN. This means that software generating the SCN can be allowedoperate in isolation—it does not have to be in communication with theback-end software—and thus it can be embedded in a credit card or otherstandalone device.

The inventions described above can be implemented by a money source foruse with an electronic card. It is preferable that every user accountutilizes the same Pseudo Random Number Generator (PRNG), such as thePRNG described in P. L'Ecuyer, “Efficient and Portable Combined RandomNumber Generators”, Communications of the ACM, 31(6):742-749,774, 1988,the disclosure of which is specifically incorporated herein byreference. However, each cardholder account has a different initialseed, and thus uses a different part of the PRNG sequence. Since thePRNG has an overall period of 10¹², there is ample room for each accountto have its own non-repeating subsequence of 10,000 values.

The PRNG is divided into two parts: seed generation (Formula 2) andvalue calculation (Formula 3). In these formulas (expressed using C codefragments), the set (S_(x) ⁰, S_(x) ¹, S_(x) ²) is a triplet offive-digit values in the range ([1, 32362], [1, 31726], [1, 31656]), andrepresents the seed in the x^(th) location in the sequence. Z is interimstorage for the pseudo random number, and PRNG[x] indicates the pseudorandom number in the x^(th) location in the sequence. Note that for thepractical usage of this algorithm, “x” corresponds to the currentCounter value. For each transaction, Formula 2 generates the seed (basedon the previous seed) and Formula 3 generates the PRNG value.$\begin{matrix}{{{Formula}\quad 2\text{:}}\quad{{PRNG}\quad{Value}\quad{Calculation}}\quad{{Z = {S_{x}^{0} - S_{x}^{1}}};}\quad{{{{if}\quad\left( {Z > 706} \right)Z} = {Z - 32362}};}\quad{{Z = {Z + S_{x}^{2}}};}\quad{{{{if}\quad\left( {Z < 1} \right)Z} = {Z + 32362}};}\quad{{{PRNG}\quad\lbrack x\rbrack} = Z}} & \quad\end{matrix}$ Formula  3:   PRNG  Seed  Generation  S_(x)⁰ = (S_(x − 1)⁰ * 157)  mod  32363  S_(x)¹ = (S_(x − 1)¹ * 146)  mod  31727  S_(x)² = (S_(x − 1)² * 142)  mod  31657

In all cases, the initial PRNG seed (which generates value 0 in the PRNGsequence) is pre-assigned to the card. Additionally, the most recentlyused seed is stored in Random Access Memory (RAM). Thus, when an SCNmust be generated, the card runs through both Formulas 2 and 3 exactlyonce, and then updates the seed storage in RAM. The Counter value isalso stored in RAM, and is initialized to the value of 1 at the time thecard is manufactured. Multiple values of the Counter are stored todetect accidental corruption. Each time an SCN is generated, the currentvalue of the Counter is used. The Counter is then incremented by 1, andstored again for the next use.

Since the SCN is calculated in an algorithmic fashion, it is possible topre-calculate the values for a given first entity, and store them on anelectronic card. This embodiment is most useful where it is moreadvantageous to store a large amount of data on the electronic card thanit is to perform the algorithms discussed above.

Use of the SCN technology described herein is secure when it requiresthe cardholder to enter a PIN in order to generate a unique SCN that isvalid for only one transaction, and for only the specified cardholder.At no time during the transaction is the PIN at risk. By utilizing bothencryption and random number generation technologies described herein,it is possible to achieve at least a 99.9% level of protection againstfraud.

FIG. 1 illustrates a method, set forth by way of example and notlimitation, in accordance with certain embodiments as disclosed herein.An exemplary Method for Generating Customer Secure Card Numbers Subjectto Use by an Electronic Card begins at 10. Next, in an operation 12, aFirst Entity is provided with an Electronic Card containing a FirstEntity Identifier, Secure Card Cumber (SCN) Generator, Pseudo RandomNumber Generator (PRNG), and Triple DES (TDES) Encryption Keys.Operation 14 allows the First Entity to enter a Personal IdentificationNumber (PIN) into the Electronic Card. The Electronic Card enters thePIN into the SCN generator in an operation 16. Next, in an operation 18,the Electronic Card generates an appropriate Transaction InformationBlock (TIB) and, in an operation 20, a next Counter Block. TheElectronic Card further generates a Sequence Insertion Number (SIN)using the PRNG and Counter Block in an operation 22, an Encrypted PINBlock using the PIN, SIN and TDES Encryption Keys in an operation 24,and finally the SCN using the TIB, Counter Block and Encrypted PIN Blockin an operation 26.

With continuing reference to FIG. 1, the First Entity Identifier and SCNare transferred from the First Entity to a Second Entity in an operation28. In an operation 30, the First Entity Identifier and the SCN aretransferred from the Second Entity to the Money Source. In an operation32, the Money Source uses the First Entity Identifier to lookup PRNG,PIN and TDES Encryption Keys such that the Money Source can extract theEncrypted PIN Block from the received SCN in an operation 34. The MoneySource then enters the PIN into the SCN generator in an operation 36,and then extracts the TIB from the received SCN in an operation 38.Next, the Money Source extracts the Counter Block from the received SCNin an operation 40 and then generates the SIN using the PRNG and theCounter Block in an operation 42. In an operation 44, the Money Sourcegenerates the Encrypted PIN Block using the PIN, SIN, and TDESEncryption Keys. Lastly, in an operation 46, the Money Source validatesthe SCN by comparing the received PIN Block against the generated PINBlock.

FIG. 1A shows the physical layout for an especially preferred embodimentof the present electronic device or Universal Anonymous Credit Card(UACC) 101. The areal dimensions of the UACC 101 are 3.375″.times.2.125″or exactly those of a regular magnetic stripe credit card in use inelectronic commerce today. The thickness of the UACC 101 varies from.about.0.030″ at the top where the magnetic stripe resides to0.030″-0.060″ for the rest of the card dependent upon the thickness ofthe LCD used (see FIG. 1). Besides the ON/OFF switch 103, the front side102 of this UACC 101 has five (5) more functional switches, 104-108,labeled and defined as follows: ATM (switch 104)=Reserved for AutomaticTeller Machine (ATM) card ACC (switch 105)=Reserved for Anonymous CreditCard (ACC or A-Card) IC (switch 106)=Reserved for Internet Type II CashMC (switch 107)=Reserved for standard Magnetic Stripe Credit Card BC(switch 108)=Reserved for A-Card transactions using bar codes

In addition to the switches 103-108, there is a 12-character keypad 109.The primary function of the keypad 109 is for the cardholder to enterthe PIN into the UACC 101 for generating the ACCN for on and offInternet commerce transactions. There is also a 10-or more characteralphanumeric liquid crystal display (LCD) 110 on the front side 102 ofthe UACC 101. This LCD 110 displays the alias and the ACCN for use forInternet commerce transactions or the alias and bar code representingthe ACCN after the cardholder's PIN is entered. The display of the ACCNwill automatically erase itself after about 2 minutes to avoid exposingsignificant information to third parties.

At the top of the back side 111 of UACC 101 is a standard 3-trackmagnetic stripe 1 112 found in every common magnetic stripe credit cardin use today. Track-1 113 and track-3 114 are used to store the relevantinformation about the cardholder such as primary account number VCCN,name, expiration date, encrypted PIN etc. Track-2 115 of the magneticstripe 112 normally contains only the cardholder's VCCN to be read by amagnetic stripe reader at the merchant's site. For the present UACCdevice, the ACCN, instead of the VCCN, will be generated on command byentering the PIN with the appropriate function switch “MC” 107 by aspecial encoder 116 located at a designated location underneath themagnetic strip 112. As will be explained in more detail below, thegenerated ACCN which resides temporarily on Track-2 115 of the magneticstripe 112 will disappear automatically 2 minutes after it is beinggenerated. This is to ensure that no significant information about thecredit card account stays long enough for fraudsters to steal forcommitting subsequent credit card frauds.

Although the foregoing detailed description is illustrative of preferredembodiments of the present invention, it is to be understood thatadditional embodiments thereof will be obvious to those skilled in theart. For example, the same inventive concepts disclosed herein could beused in a system in which a customer has two or more account numbersand/or identities, with the same or different user keys. In the case ofan electronic card or telephone, this would allow the customer to selectwhich account should be used (for example, to choose a business creditcard for use with a business expense, a personal credit card for usewith a personal expense, or a bank card at a local store for groceriesand cash back). Alternatively, a customer might be permitted to usemultiple user keys for the same account number and the same identity.This could allow some of the same functionality, or it could be used toclassify the type or nature of the expense or transaction. Furthermore,the same SCN concept can be easily extended to non-financialtransactions where user authentication is required, such as withelectronic Identification cards. Further modifications are also possiblein alternative embodiments without departing from the inventive concept.

Accordingly, it will be readily apparent to those skilled in the artthat still further changes and modifications in the actual conceptsdescribed herein can readily be made without departing from the spiritand scope of the disclosed inventions as defined by the followingclaims.

1. An apparatus for conducting secure transactions between a firstentity and at least one additional entity, comprising: a memory; aprocessor coupled to the memory; a secret key embodied in the memory; anapplication embodied in the memory, the application includinginstructions, which, when executed by the processor, cause the processorto: maintain a counter; calculate a dynamic digital signature based onthe secret key and the counter; and transmit at least a portion of thedynamic digital signature in a non-account data field of track imagedata formatted as a standard payment card magnetic stripe track, over apayment network.
 2. The apparatus of claim 1, wherein: the applicationin the apparatus also includes instructions, which, when executed by theprocessor, cause the processor to: transmit at least a portion of thecounter block with the dynamic digital signature.
 3. The apparatus ofclaim 1, wherein: the application in the apparatus also includesinstructions, which, when executed by the processor, cause the processorto: transmit a TIB, in a portion of a non-account data field of trackimage data formatted as a standard payment card magnetic stripe track,over the payment network.
 4. The apparatus of claim 1, wherein: the TIBencodes information indicating whether a transaction requires validationof an associated cryptogram.
 5. The apparatus of claim 1, wherein: theTIB encodes information indicating a transaction mode.
 6. The apparatusof claim 5, wherein: the transaction mode is selected from the groupincluding mail order, telephone, internet and brick-and-mortar.
 7. Theapparatus of claim 1, wherein: the application in the apparatus alsoincludes instructions, which, when executed by the processor, cause theprocessor to: transmit a PIN, in a portion of track image data formattedas a standard payment card magnetic stripe track, over the paymentnetwork.
 8. The apparatus of claim 1, wherein: the application in theapparatus also includes instructions, which, when executed by theprocessor, cause the processor to: receive a PIN entered by a user atthe apparatus.
 9. The apparatus of claim 1, wherein: the apparatus is tobe used with equipment supplied by the additional entity, and theequipment supplied by the additional entity is to receive a PIN from auser concurrently with transmission over the payment network.
 10. Theapparatus of claim 9, wherein: the application in the apparatus alsoincludes instructions, which, when executed by the processor, cause theprocessor to: transmit a PIN, in a portion of track image data formattedas a standard payment card magnetic stripe track over the paymentnetwork.
 11. The apparatus of claim 1, wherein: the non-account datafield is at least one of a discretionary data field, a date data field,a cardholder name data field, a country code data field and a servicecode data field.
 12. An electronic card for conducting securetransactions between a first entity and at least one additional entity,comprising: a memory; a processor coupled to the memory; a predeterminedkey value embodied in the memory; an application embodied in the memory,the application including instructions, which, when executed by theprocessor, cause the processor to: maintain a counter; calculate adynamic digital signature based on the predetermined key value and thecounter; and transmit at least a portion of the dynamic digitalsignature in a non-account data field of a track image data structureover a payment network.
 13. The electronic card of claim 12, wherein:the application in the apparatus also includes instructions, which, whenexecuted by the processor, cause the processor to: transmit at least aportion of the counter block with the dynamic digital signature.
 14. Theelectronic card of claim 12, wherein: the application in the apparatusalso includes instructions, which, when executed by the processor, causethe processor to: transmit a PIN in the track image data structure overthe payment network.
 15. The electronic card of claim 12, wherein: theapparatus is to be used with equipment supplied by the additionalentity, and the equipment supplied by the additional entity is toreceive a PIN from a user concurrently with transmission over thepayment network.
 16. The electronic card of claim 15, wherein: theapplication in the apparatus also includes instructions, which, whenexecuted by the processor, cause the processor to: transmit a PIN in thetrack image data structure over the payment network.
 17. The electroniccard of claim 12, wherein: the application in the apparatus alsoincludes instructions, which, when executed by the processor, cause theprocessor to: receive a PIN entered by a user at the apparatus.
 18. Theelectronic card of claim 12, wherein: the application in the apparatusalso includes instructions, which, when executed by the processor, causethe processor to: transmit a restriction and status identifier in thetrack image data structure over the payment network.
 19. The electroniccard of claim 12, wherein: the restriction and status identifier encodesinformation indicating whether a transaction requires validation of anassociated cryptogram
 20. The electronic card of claim 12, wherein: therestriction and status identifier encodes information indicating atransaction mode.
 21. The electronic card of claim 20, wherein: thetransaction mode is selected from the group including mail order,telephone, internet and brick-and-mortar.
 22. A method of conducting asecure transaction between a first entity and a second entity with anelectronic card, comprising: maintaining a counter embodied in the card;calculating a dynamic digital signature in the card based on apredetermined key value and the counter; and transmitting at least aportion of the dynamic digital signature in a non-account data field ofa track image data structure over a payment network.
 23. The method ofclaim 22, further comprising: transmitting a PIN embodied in the card inthe track image data structure over the payment network.
 24. The methodof claim 22, further comprising: transmitting at least a portion of thecounter block with the dynamic digital signature.
 25. The method ofclaim 22, further comprising: transmitting a restriction and statusidentifier embodied in the card in the track image data structure overthe payment network.
 26. The method of claim 22, wherein: the card is tobe used with equipment supplied by the second entity; and furthercomprising: receiving a PIN at the equipment from a user concurrentlywith transmission over the payment network.
 27. The method of claim 22,wherein: the non-account data field is at least one of a discretionarydata field, a date data field, a cardholder name data field, a countrycode data field and a service code data field.